1. Field of the Invention
The present invention relates to the field of computer systems. More specifically, the present invention relates to the regulation of objects in distributed computer systems.
2. Description of Related Art
In a distributed system such as an automated teller machine (ATM) network, a client such as an individual ATM machine is serviced by a server such as the computer system of the bank whose transaction processing includes interfacing with the ATM machine. The ATM network is a xe2x80x9cdistributedxe2x80x9d system since there can be many clients attached to one or more servers which transact information (objects) amongst one another. Traditionally, distributed objects were forced to obey a common xe2x80x9cspecificationxe2x80x9d which are the rules and semantics the objects are governed by. For example, the account balance of a bank patron is an object which is distributed. A rule or specification is that the withdrawal cannot exceed the account balance, and this specification is common to both client and server. A specification common to both client and server ends is referred to as a public contract.
In distributed systems, there are also private constraints which need to be obeyed on only one side, either client or server, but not both. Examples of private constraints include debiting the overall asset column of the bank""s balance sheet when a withdrawal is made. The constraint is private to the server since the client is not involved in nor affected by the bank""s overall asset accounting. A constraint private to the client is that the amount sought to be withdrawn by the patron must be physically available in the coffers of the ATM machine. The server is not involved in deciding whether or not the currency is available at the ATM machine. Thus, the constraint is private to the client.
To guarantee that a distributed system has good reliability, both private constraints and public contracts must be checked. However, in traditional distributed systems, no attempt was made to automatically check private constraints and in fact, private constraints were not considered as such. Checking, which involves testing to see if the contract or constraint is met, was therefore only performed on public contracts, and not automatically. Even when checked, the problem of latency in server-to-client networking has not been adequately addressed. In the ATM network, when the account balance is passed on to the server, for display to the user, there is latency inherent in communicating the balance. In the meantime, while the balance is being displayed to the user, another debit transaction may be occurring at the server itself which changes the balance. If the balance is not updated to the client until another request or transaction occurs, then the amount is incorrect. Further, while money is being withdrawn on the ATM, due to latency in communicating the transaction back to the server, the server will temporarily have an inaccurate balance.
Thus, there is need to automatically check both private constraints and public contracts to guarantee that objects reliably follow specifications in a distributed system.
In a distributed system, objects which are transacted between clients and servers must obey certain rules or specification. A specification is composed of two types of rules: public contracts and private constraints.
Public contracts are obeyed by both client and server. Private constraints are obeyed by either client or server, but for a given private constraint, not by both. At each stage of a client-to-server or server-to-client transaction or xe2x80x9ccallxe2x80x9d, the objects or parameters related to call are processed before transfer. In a client call, a client-side stub performs marshalling of objects related to the call in order to transfer them over the network. The client-side stub, according to the present invention, automatically generates code to check both private client-side constraints and public contracts between server and client before the transfer occurs. Once the client-side specification is checked, the marshalled objects and client call are transferred over the network to the server.
The server has a server-side skeleton which intercepts the call and marshalled objects. The skeleton unmarshals the objects and performs checking by code automatically generated to check the public contracts, if any, with client and any private server-side constraints. Once checking is complete, the call is processed and a server xe2x80x9creturn resultsxe2x80x9d. The return object is marshalled and checked at the skeleton and then transferred across the network to the client. The client-side stub unmarshals the return object and then performs checking according to its specification which may be different from the specification checked for objects related to the call.